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ABSTRACT 



An optical access network and method for transmitting 
optical data in the network utilizes an interleaved polling 
scheme to efficiently use the available bandwidth of the 
network. The use of the interleaved polling scheme allows a 
central terminal of the network to dynamically allocate 
upstream bandwidth from remote terminals of the network 
to the central terminal in response to the amount of data that 
is waiting at the remote terminals to be transmitted to the 
OLT In one embodiment, the optical access network is 
based od Passive Optical Network (PON) technology. In 
another embodiment, the optical access network utilizes 
Ethernet protocol to encapsulate data in Ethernet frames for 
transmission. Thus, in these embodiments, the optical access 
network includes all of the advantages associated with the 
PON technology and/or. the Ethernet protocol. In addition, 
since the allocation of upstream bandwidth is on an as 
needed basis, loss of bandwidth due to unfilled time slots is 
substantially eliminated. 

/ ; 43 Claims, 12 Drawing Sheets 
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METHOD AND SYSTEM FOR DYNAMIC 
BANDWIDTH ALLOCATION IN AN 
OPTICAL ACCESS NETWORK 

FIELD OF THE INVENTION 

The invention relates generally to access networks, and 
more particularly to a passive optical access network. 

BACKGROUND OF THE INVENTION 

The explosion of the Internet and the desire to provide 
multiple communications and entertainment services to end 
users have created a need for a broadband network archi- 
tecture that improves access to end users. Although the 
bandwidth of backbone networks has experienced a sub- 
stantial growth in recent years, the bandwidth provided by 
access networks has remained relatively unchanged. Thus, 
the "last mile" still remains a bottleneck between a high 
capacity LAN or Home network and the backbone network 
infrastructure. 

Digital Subscriber Line (DSL) and Cable Modem (CM) 
technologies offer some improvements over more conven- 
tional last mile solutions. However, these technologies still 
do not provide enough bandwidth to support emerging 
services such as Video-On-Demand (VoD) or two-way video 
conferencing. In addition, not all customers can be covered 
by DSL and CM technologies due to distance limitations. 

One broadband access network architecture that offers a 
solution to the "last mile" problem is a point-to -multipoint 
passive optical network (PON). A point-to-multipoint PON 
is an optical access network architecture that facilitates 
broadband communications between an optical line terminal 
(OLT) and multiple remote optical network units (ONUs) 
over a purely passive optical distribution network. A point- 
to-multipoint PON utilizes passive fiber optic splitters and 
combiners to passively distribute optical signals between the 
OLT and the remote ONUs. 

FIGS. 1A and IB illustrate the management of network 
traffic in a point-to-multipoint PON. As an example, the 
PON is shown to include an OLT 102 and three ONUs 104, 
106 and 108, although the PON may include additional 
ONUs. Referring to FIG. 1A, the OLT includes an optical 
transmitter 110 that sends downstream traffic containing 
ONU-specific information blocks 1, 2 and 3 to the ONUs. 
The downstream traffic is optically broadcasted by a passive 
optical splitter/combiner 112 into three separate signals that 
each carries all of the ONU-specific information blocks. The 
ONUs 104, 106 and 108 include optical receivers 114, 116 
and 118, respectively, that receive all the information blocks 
transmitted by the OLT Each ONU then processes the 
information blocks that are intended for that ONU and 
discards the information blocks that are intended for the 
other ONUs. For example, ONU-1 receives information 
blocks 1, 2, and 3. However, ONU-1 only delivers infor- 
mation block 1 to end user 1. Likewise, ONU-2 only delivers 
information block 2 to end user 2 and ONU-3 only delivers 
information block 3 to end user 3. 

Referring to FIG. IB, the ONUs 104, 106 and 108 also 
include optical transmitters 120, 122 and 124, respectively, 
to transmit upstream traffic to OLT 102. The upstream traffic 
is managed utilizing a time division multiplex access 
(TDMA) protocol, in which specific transmission time slots 
are dedicated to individual ONUs. Hie ONU-specific time 
slots are synchronized so that upstream information blocks 
from the ONUs do not interfere with each other once the 
information blocks are combined onto the common fiber. 
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For example, ONU-1 transmits information block 1 in a first 
ONU-specific time slot, ONU-2 transmits information block 
2 in a second ONU-specific time slot, and ONU-3 transmits 
information block 3 in a third ONU-specific time slot. The 

s lime division multiplexed upstream traffic is then received 
by an optical receiver 126 of the OLT. 

A concern with a TDMA PON is that the bandwidth of the 
PON is not always efficiently utilized for data transmission 
because network traffic typically exhibits a high degree of 

10 burstiness. The bursty network traffic results in some trans- 
mission time slots that consistently overflow even under a 
very light traffic load. In addition, the bursty network traffic 
results in some transmission time slots that are not com- 
pletely filled even when the overall traffic load is very high. 

15 In view of the above concern, there is a need for an access 
network based on PON technology that efficiently utilizes 
the available bandwidth by reducing the amount of band- 
width wasted because transmission time slots are not filled 

^ to the maximum capacity. 

SUMMARY OF THE INVENTION 

An optical access network and method for transmitting 
optical data in the network utilizes an interleaved polling 

25 scheme to efficiently use the available bandwidth of the 
network. The use of the interleaved polling scheme allows a 
central terminal of the network to dynamically allocate 
upstream bandwidth from remote terminals of the network 
to the central terminal in response to the amount of data that 

3 q is waiting at the remote terminals to be transmitted to the 
OLT. In one embodiment, the optical access network is 
based on Passive Optical Network (PON) technology. In 
another embodiment, the optical access network utilizes 
Ethernet protocol to encapsulate data in Ethernet frames for 

3S transmission. Thus, in these embodiments the optical access 
network includes all of the advantages associated with the 
PON technology and/or the Ethernet protocol. In addition, 
since the allocation of upstream bandwidth is on an as 
needed basis, loss of bandwidth due to unfilled time slots is 

40 substantially eliminated. 

A method of transmitting optical data in an optical net- 
work in accordance with the invention includes the steps of 
generating a table that includes information about the cur- 
rent sizes of data waiting to be transmitted from a plurality 

45 of remote terminals to a central terminal, selectively trans- 
mitting grant messages to the remote terminals, receiving 
authorized amounts of the data from the remote terminals 
and request messages containing updated information about 
the current sizes of the data waiting to be transmitted at the 

50 remote terminals in response to the grant messages, and 
updating the table using the updated information contained 
in the request messages received from the remote terminals. 
Each grant message is indicative of a permission for a 
targeted remote terminal to transmit an authorized amount of 

55 data waiting at the targeted remote terminal, which is 
dependent on the information included in the table with 
regard to the targeted remote terminal. In an embodiment, 
the optical network is a passive optical network (PON), 
which may be an Ethernet-based PON. 

60 In an embodiment, the table that-includes information 
about the current sizes of data waiting to be transmitted from 
the plurality of remote terminals further includes informa- 
tion about round trip times of data transmission between the 
central terminal and the remote terminals. In this 

65 embodiment, the method may include steps of computing 
current round trip times for the remote terminals, including 
monitoring transmission times associated with the grant 
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messages from the central terminal and reception times 
associated with the authorized amounts of the data from the 
remote terminals, and updating the information about round 
trip times of data transmission using the computed current 
round trip times. S 

In an embodiment, the step of updating the table includes 
subtracting a value from a new entry for the targeted remote 
terminal. The value corresponds to the actual amount of data 
transmitted from said targeted remote terminal, while the 
new entry corresponds to the updated information contained 10 
in a request message from the targeted remote terminal. 

In an embodiment, the method may further include a step 
of scheduling transmission times for the grant messages 
such that the data and the updated information from the 
remote terminals do not overlap during transmission. The 15 
transmission times for the grant messages substantially 
define receptions times for the request messages at the 
central terminal. The step of scheduling transmission times 
may include rescheduling an original transmission time for 
a grant message to a rescheduled transmission time when the 10 
original transmission time conflicts with anther transmission 
time for a different grant message. 

In an embodiment, the method further includes steps of 
detecting a disconnected remote terminal, and reducing the 
frequency of grant messages that are transmitted to the 
disconnected remote terminal. The step of detecting a dis- 
connected remote terminal may include waiting a predefined 
period for the disconnected remote terminal to respond to a 
grant message transmitted to the disconnected remote ter- 
minal. 

An optical access network in accordance with the inven- 
tion includes a plurality of remote terminals and a central 
terminal. In one embodiment, the optical access network is 
an Ethernet-based PON. The remote terminals of the net- 
work receive and transmit optical data. Each remote terminal 
is configured to transmit a request message and an autho- 
rized amount of data waiting at the remote terminal in 
response to a grant message received by the remote terminal. 
The request message includes updated information about the 4Q 
current size of data waiting at the remote terminal, while the 
grant message includes information that indicates the autho- 
rized amount. The central terminal of the network is opti- 
cally coupled to the remote terminals to transmit and receive 
the optical data. 45 

The central terminal includes memory that has a table 
containing latest information about the current sizes of data 
waiting to be transmitted from the remote terminals to the 
central terminal, and a processor that is configured to 
selectively transmit grant messages to the remote terminals 50 
using the latest information contained in the table to indicate 
authorized amounts of data that can be sent by receiving 
remote terminals. The processor of the central terminal is 
further configured to receive request messages from the 
remote terminals in response to the grant messages and to S5 
update the table in memory using the updated information 
contained in the request messages. 

In an embodiment, the processor of the central terminal is 
configured to update the table in memory by subtracting 
values from new entries for selected remote terminals that 60 
have transmitted the request messages to the central termi- 
nal. The values correspond to the actual amounts of data 
transmitted from the selected remote terminals, while the 
new entries correspond to the updated information contained 
in the request messages. 65 

In an embodiment, the processor of the central terminal is 
further configured to schedule transmission times for the 
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grant messages such that the data and the request messages 
from the remote terminals do not overlap during transmis- 
sion. In this embodiment, the processor may be further 
configured to reschedule an original transmission time for a 
specific grant message to a rescheduled transmission rime 
when the original transmission time conflicts with another 
transmission time for a different grant message. 

In an embodiment, the processor of the central terminal is 
configured to detect disconnected remote terminals by iden- 
tifying the remote terminals that have not responded to the 
grant messages within a timeout period. In this embodiment, 
the processor may be configured to reduce the frequency of 
grant messages mat are transmitted to the disconnected 
remote terminals. 

In an embodiment, the table in memory further includes 
information about round trip times of data transmission 
between the central terminal and the remote terminals. In 
this embodiment, the processor of the central terminal may 
be configured to compute current round trip times for the 
remote terminals by monitoring transmission times associ- 
ated with grant messages from the central terminal and 
reception times associated with request messages from the 
remote terminals and to update the information about round 
trip times using the current round trip times. 

Other aspects and advantages of the present invention will 
become apparent from the following detailed description, 
taken in conjunction with the accompanying drawings, 
illustrated by way of example of the principles of the 
invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1A illustrates the downstream flow of traffic from an 
OUT to multiple ONUs in a point- to -multipoint PON. 

FIG. IB illustrates the upstream flow of traffic from the 
ONUs to the OLT in the point-to-multipoint PON. 

FIG. 2 is a block diagram of an optical access network 
based on PON technology in accordance with the present 
invention. 

FIGS. 3-8 illustrate the polling scheme of the optical 
access network. 

FIG. 9 illustrates the embedding of a GRANT message in 
an Ethernet frame by the OLT using an escape code. 

FIG. 10 is a flow diagram of an operation of the OLT with 
respect to GRANT message scheduling conflicts. 

FIG. 11 is a process flow diagram of a detecting and 
polling procedure of the OLT with respect to disconnected 
ONUs. 

FIG. 12 is a process flow diagram of a method of 
transmitting optical data in the optical access network in 
accordance with the present invention. 

DETAILED DESCRIPTION OF THE 
INVENTION 

With reference to FIG. 2, an optical access network 202 
that utilizes an interleaved polling scheme in accordance to 
the present invention is shown. The optical access network 
is based on Passive Optical Network (PON) technology. 
Therefore, the optical access network embodies the advan- 
tages associated with a PON. Furthermore, the interleaved 
polling scheme of the optical access network efficiently 
utilizes the available bandwidth of the network by allocating 
bandwidth on an as needed basis. 

In an exemplary embodiment, the optical access network 
202 utilizes the IEEE 802.3 protocol (commonly referred to 
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as Ethernet) to encapsulate data in Ethernet frames for 
transmission. Although the optical access network 202 may 
utilize other protocols, such as ATM data link protocol, the 
use of Ethernet protocol is preferred. Currently, about 
ninety-five percent (95%) of LANs use the Ethernet proto- 
col. Therefore, an Ethernet-based PON is much more pref- 
erable than an ATM-based PON to interconnect Ethernet 
networks. In addition, ATM imposes a cell tax on variable 
length IP packets, since an IP packet that is longer than 48 
bytes must be transmitted in two or more ATM cells. As the 
number of ATM cells increase, the bandwidth consumed by 
header information increases accordingly. Furthermore, 
ATM equipment is more expensive than Ethernet equip- 
ment. 

The optical access network 202 includes an optical line 
terminal (OLT) 204, which can be considered as a central 
terminal of the network, and a plurality of optical network 
units (ONUs) 206, 208 and 210, which can be considered as 
remote terminals of the network. For illustrative purposes, 
the optical access network is described as including only 
three ONUs, although the network may include additional 
ONUs. Furthermore, although the optical access network is 
shown as being configured in a tree topology, the optical 
access network may be configured in other network 
topologies, such as a ring topology or a bus topology. The 
topology of the optical access network is not critical to the 
invention. 

Each ONU 206, 208 or 210 of the optical access network 
202 includes a buffer 212, an optical transceiver 214 and an 
ONU processor 216. Each buffer of the ONUs operates as a 
temporary storage medium to store bytes of data that are to 
be transmitted to the OLT 204. The bytes of data stored in 
the buffer include data from end users (not shown) supported 
by the respective ONU. Each optical transceiver of the 
ONUs operates to transmit some or all of the bytes of data 
stored in the buffer as Ethernet frames in the form of optical 
signals to the OLT. In addition, each optical transceiver 
operates to receive optical signals from the OLT. Each ONU 
processor of the ONUs performs various operations to 
ensure that the respective ONU is properly functioning. 
Furthermore, each ONU processor executes steps in accor- 
dance with the interleaved polling scheme of the optical 
access network, which is described in detail below. 

The OLT 204 of the optical access network 202 includes 
an optical transceiver 218, an OLT memory 220 and an OLT 
processor 222. The optical transceiver of the OLT is similar 
to the optical transceivers 214 of the ONUs 206, 208 and 
210. The OLT optical transceiver operates to transmit optical 
signals to the ONUs, and to receive optical signals from the 
ONUs. The OLT memory 220 stores a polling table 224 to 
facilitate the interleaved polling scheme of the optical net- 
work access. The OLT memory may be any type of storage 
medium, such as DRAM or FPGA. Although the OLT 
memory is shown in FIG. 2 as a separate component from 
the OLT processor, the OLT memory may instead be incor- 
porated in the OLT processor. The polling table is illustrated 
as having exemplary data for a particular instant. The polling 
table includes information regarding the ONUs supported by 
the OLT This ONU information is illustrated in the, column 
of the polling table under the heading "ONU". The polling 
table also includes information about the number of bytes of 
data buffered at each of the ONUs waiting to be transmitted 
to the OLT The buffered data information is illustrated in the 
column of the polling table under the heading "Bytes". 
Furthermore, the polling table includes information about 
the round-trip times (RTIs) for data to travel between the 
OLT and the ONUs. The RTT information is illustrated in 
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the column of the polling table under the heading "RTT*. An 
RTT value included in the polling table includes the actual 
RTT as well as processing times required to process and 
generate control messages. The polling table stored in the 
memory of the OLT is used by the OLT processor to 
efficiently regulate the network traffic between the OLT and 
the ONUs using the interleaved polling scheme. 

The optical access network 202 also includes at least one 
optical splitter/combiner 226 and optical fibers 228, 230, 
232 and 234 that provide connections between the OLT 204 
and the ONUs 206, 208 and 210 through the optical splitter/ 
combiner. The optical fiber 228 connects the OLT to the 
optical splitter/combiner. The optical fibers 230, 232 and 
234 connect the optical splitter combiner to the ONUs 206, 
208 and 210, respectively. The optical fibers 228, 230, 232 
and 234 may be used for both downstream (OLT to ONUs) 
and upstream (ONUs to OLl^ data transmissions. In an 
alternative configuration, these optical fibers may be used 
for only one-way data transmissions. In such a 
configuration, the optical access network includes dual 
optical fibers to allow two-way data transmissions. 

The operation of the optical access network 202 with 
respect to downstream traffic management is similar to the 
operation of a traditional Ethernet network, which by design 
broadcast data throughout the Ethernet network. In the 
downstream direction, optical Ethernet frames are broadcast 
by the OLT 204 and then extracted by their destination ONU 
based on the media-access control (MAC) addresses of the 
frames. Therefore, in the downstream direction, there is no 
issue of competing bandwidth usages since the OLT is the 
only data-transmitting source. Consequently, the total avail- 
able bandwidth is almost fully utilized in the downstream. 
However, in the upstream direction, ONUs must share the 
channel capacity of the optical fiber 228 and other resources. 
The upstream bandwidth of the optical access network is 
clearly limited as the sum of peak ingress rates R^ of all 
ONUs 206, 208 and 210 exceeds the PON throughput R^, or 
the upstream channel capacity. Furthermore, since network 
traffic typically exhibits a high degree of burstiness, a 
time-division multiple access (TDMA) system with fixed 
time slots cannot fully utilize the upstream bandwidth. In 
TDMA systems, the bursty network traffic results in some 
transmission time slots that consistently overflow even 
under a very light traffic load. In addition, the bursty traffic 
results in some transmission time slots that are not com- 
pletely filled even when the overall traffic load is very high. 

In contrast to the TDMA systems with fixed time slots, the 
optical access network 202 maximizes the upstream band- 
width utilization by using an interleaved polling scheme to 
manage upstream traffic. The polling scheme of the optical 
access network is described with reference to FIGS. 3-8 
using specific values as examples, such as the byte sizes of 
data in buffers of the ONUs and the RTT values for each 
ONU. 

For a given moment of time (t=0) after the initialization 
of the OLT 204, a polling table 302 stored in the memory 
220 of the OLT is assumed to be current, as illustrated in 
FIG. 3. That is, the polling table includes updated informa- 
tion about the active ONUs, the number of bytes waiting at 
each ONU's buffer, and the round-trip time (RTT) for each 
ONU. At t-0, the current polling table includes the follow- 
ing information. For the ONU-1, there are 1200 bytes of data 
waiting in the buffer 212 and the RTT is 200 fits. For the 
ONU-2, there are 400 bytes of data waiting in the buffer 212 
and the RTT is 170 /zs. For the ONU-3, there are 2500 bytes 
of data waiting in the buffer 212 and the RTT is 120 ^s. 

As illustrated in FIG. 3, at time t=0, the OLT204 transmits 
an ONU control message 304 to the ONU-1, which autho- 
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rizes the ONU-1 to send 1200 bytes of data that is currently 
in the buffer 212 of the ONU-1. Such a message will be 
referred to herein as a GRANT message. Since the OUT 
broadcasts data to all ONUs in the downstream direction, a 
GRANT message contains identification of so the destina- 
tion ONU in a NID ("node identification") field 306, as well 
as the size of the granted window in bytes in a WS ("window 
size") field 308, as illustrated by the GRANT message 304. 
The GRANT message 304 is then received by the ONU-1, 
at time t=t=tl. The time tl is approximately half of the RTT 
for the ONU-1. By the time the GRANT message is received 
by the ONU-1, additional bytes of data may have been 
received by the buffer of the ONU-1. As an example, the 
ONU-1 may have received an additional 3100 bytes of data. 
Therefore, the total number of bytes in the buffer of the 
ONU-1 is 4300 (1200+3100) bytes of data. 

Upon receiving the GRANT message 304, the ONU-1 
sends an OLT control message 402 to the OUT 204, as 
illustrated in FIG. 4. Such a message will be referred to 
herein as a REQUEST message. Similar to a GRANT 
message, a REQUEST message also includes an NID field 
404 and a WS field 406. The WS field includes the current 
bytes of data waiting in the buffer of a particular ONU when 
the REQUEST message was generated. Thus, the 
REQUEST message 402 will indicate that 4300 bytes of data 
are currently waiting in the buffer 212 of the ONU-1. The 
REQUEST message tells the OLT how many bytes of data 
are in the buffer of the ONU-1 at the moment when the 
REQUEST message was generated. The ONU-1 also sends 
data 408 stored in the buffer of the ONU-1 up to the size of 
the granted window. In this example, the ONU-1 sends 1200 
bytes of the data from the buffer of the ONU-1. 

Even before the OLT 204 receives the REQUEST mes- 
sage 402 from the ONU-1, the OLT knows the time i x last 
when the last bit of transmission from the ONU-1 will arrive 
at the OLT From the RTT information in the current polling 
table 302, the OLT knows when the first bit from ONU-1 
will arrive at the OLT. The first bit will arrive exactly after 
the RTT for the ONU-1. In addition, the OLT knows how 
many bytes (bits) will arrive at the OLT, since the OLT has 
authorized the ONU-1 to send a specific number of bytes by 
the GRANT message 304 to the ONU-1. Thus, the time i**" 
can be derived as follows: 



= /f + R 77} + 



WSi 



LineJ^ate 



0 + 200 us + 



hits 

1200 bytes X 8 

byte 



= 209.6 ms 



collision with data from the ONU-1. In general, guard bands 
provide protection for fluctuations of RTTs and control 
message processing times of the ONUs. 

At time t=t2, the data from the ONU-1 arrives at the OLT 

5 204 in response to the GRANT message 304 from the OLT, 
as illustrated in FIG. 6. The time t2 is approximately equal 
to the current RTT for the ONU-1. For this example, the time 
t2 equals 199 us. Since the REQUEST message 402 from the 
ONU-1 was sent first, this message is received by the OLT 

10 prior to the data 408 from the buffer 212 of the ONU-1. The 
information contained in the WS field of the REQUEST 
message 402, i.e., the number of bytes in the buffer of the 
ONU-1 when the REQUEST message was sent, is used by 
the OLT to update the polling table. The NID of the 

15 REQUEST message 402 lets the OLT know which entry of 
the polling table to update. Thus, in this example, the 
updated entry for the ONU-1 can be computed as follows: 



20 



25 



35 



40 



45 
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In the above equation, if is the time when the. GRANT 
message was sent to the ONU-1, RTTj is the RTT for 
ONU-1, WSj is the granted window size, and Line_Rate is 
the data transmission speed for the optical access network 
202. 

Since the OLT.204 knows when the last bit from the 
ONU-1 will arrive, the OLT can send a GRANT message 
502 to the ONU -2 so that the first bit of transmission from 
the ONU -2 will arrive right after the last bit of transmission 
from the ONU-1, as illustrated in FIG. 5. The time if for the 
OLT to send the GRANT message to the ONU-2 can be 
derived as follows: 

/ 2 c w, /aj/ - J R7T 2 +Gaiard_Band-209.6-l 70+5-44.6 p>. 

In the above equation, a guard band time, for example, of 5 
/is, is added to ensure that data from the ONU-2 avoids 



55 



updated_entry=new_entry-old_entry 4300-1 200=3100 bytes. 

Thus, the "Byte" entry for the ONU-1 is updated to 3100, as 
illustrated by an updated polling table 602 in FIG. 6. 
However, there may be situations when the granted window 
size is not fully filled by the data from an ONU. For 
example, if one or more higher-priority data packets arrive 
at an ONU after a Request message is sent, the ONU may 
send the higher-priority data packets before the other buff- 
ered data. The higher-priority data packets, which can have 
variable lengths, may not exactly fill the granted window 
size. The same problem will occur if an ONU requests a 
widow size greater than a maximum transmission window 
size, which is discussed below. If packet fragmentation is not 
available, then the ONU will send less data, leaving the 
remaining amount of data in the buffer. Updating the polling 
table using the above formula will result in an underesti- 
mated value for the updated_entry. An alternative approach 
would be for the OLT to update the table after all the data 
from a given ONU is received using the following formula: 

updated_entry»new entry-bytes_jeceived. 

In addition to updating the current buffered data for a 
given ONU, the OLTkeeps track of times when the GRANT 
messages and the corresponding REQUESTS are received. 
The OLT uses this information to constantly update the RTT 
entries for the respective ONUs. For this example, the actual 
RTT for the ONU-1 is 199 us. Thus, the RTT entry for the 
ONU-1 in the polling table 302 is changed from 200 us to 
199 us, as illustrated by the updated polling table 602. 

Turning now to the ONU-2, the OLT 204 calculates the 
time when the last bit from the ONU-2 will arrive at the OLT 
in the same manner as described above with respect to the 
ONU-1. Hence, the OLT will know when to send a GRANT 
message to the ONU-3 so that the data from ONU-3 will 
arrive at the OLT shortly after the data from the ONU-2. At 
time t«t3, the data from the ONU-2 arrives at the OLT, as 
illustrate in FIG. 7. When the REQUEST message from the 
ONU-2 is received by the OLT, the information contained in 
the latest polling table 602 is updated for the ONU-2, as 
illustrated by an updated polling table 702. In this example, 
the REQUEST message from the ONU-2 indicates that the 
buffer of the ONU-2 is empty, since the REQUEST message 
reported the same number of bytes as the actual number of 
bytes sent to the OLT. 

In a similar fashion, the OLT 204 calculates the time when 
the last bit of transmission from the ONU-3 will arrive at the 
OLT and sends the next GRANT message to the QNU-1, 
which starts the new polling cycle. Meanwhile, a REQUEST 



10/07/2003, EAST Version: 1.04.0000 



US 6,546,014 Bl 

9 10 

message and data from the ONU-3 are received by the OLT. r 1 ' 1 — Round-Trip Time (RTT) for f* ONU 

The REQUEST message from the ONU-3 is used by the W-''J j 1 * Window Size for i* ONU 

OLT to update the latest polling table 702 to an updated R^'-Transmission speed (bit rate) 

polling table 802, as illustrated in FIG. 8. When the ONU-2 t> n a t> ^ /• \ 

is polled in the next cycle, the grant size of the GRANT s Guard Band (in ps). 

message is zero bytes, since the latest "Bytes" entry for the In the above formula, the superscript in brackets identifies an 

ONU-2 is zero. In response to the GRANT message, the 0NU as following: 

ONU-2 again sends a REQUEST message containing the \x}-(x MODtfy+i. 
last number of bytes waiting in the buffer of the ONU-2. 

However, since the grant size of the GRANT message is in ^ t0 P hne m h me formula (1) states that the GRANT 
zero bytes, no data from the buffer of the ONU-2 is sent to 10 message to [i+lj ONU is scheduled such that the respond- 
the OLT If the buffer of the ONU-2 receives additional data m g REQUEST message arrives after the end of the trans- 
after the previous REQUEST message from the ONU-2 was mission window from i* ONU and the guard band time. The 
sent, then the ONU-2 is authorized to send the additional bottom line in the formula (1) states that the GRANT 
data in the following polling cycle. message cannot be sent before the previous REQUEST 
A concern with the polling scheme of the optical access 15 message from the same ONU is received, i.e., the interval 
network 202 is that if the OLT 204 authorizes each ONU to between successive GRANT messages to the same ONU is 
send the entire data stored in the buffer in one transmission, at least the RTT to that ONU. This requirement is necessary 
the ONUs with high data volume could monopolize the since the GRANT message needs the requested window size 
entire bandwidth. In order to avoid such monopolization, information contained in the previous REQUEST message, 
there can be a limit to the maximum transmission size for 20 from the formula (1), it can be seen that the GRANT 
each transmission. Thus, the OLT will apply this maximum meS sage to the [i+lf ONU should be sent before the 
size limit when sending the GR ANT messages. GRANT message to the i^ ONU, if the following inequality 
Consequently, every ONU will be authorized to send as ^ sa tjgfi ed 
many bytes of data in the buffer as requested in a previous 
cycle up to the maximum size limit. The maximum size limit 2 s 

may be fixed. As an example, the fixed maximum size limit ^i+i] > ^ + +B 

may be based on a Service Level Agreement for each ONU. R u 
In an alternative approach, the maximum size limit may be 

dynamic. As an example, the dynamic maximum size limit r- c « c ^r> akft u 

, *i_ 4. i*«tij Therefore, the order of GRANT messages is generally 

may be based on the average network traffic load. ' , _ CrtTTi: * & ' 

In the exemplary embodiment, the GRANT and 30 * om thc orde T ° f , F^F^J^ 

REQUEST messages are embedded between Ethernet REQUEST messages and the data, if any, from the ONUs 

frames or in an Ethernet frame using an escape sequence. arnve at the 0LT m the same order in everv c y dc * However, 

Under the Ethernet standard IEEE 802.3, Gigabit Ethernet since the GRANT messages are being scheduled with regard 

uses 8-to-10 bit encoding, i.e., every byte is being encoded t0 corresponding RTTs and granted window sizes, the order 

as 10 bits before being sent over the medium. However, not 35 of the GRANT messages may be different in every cycle, 

all of the 10-bit values are valid encoding of an 8-bit value. Scheduling a GRANT message to [i*!]* ONU ahead of 

One or more of these "non- valid" codes can be chosen to a GRANT message to 1 th ONU is not a problem, since the 

represent an escape code. A GRANT message or a order of GRANT messages is determined in a cycle prior to 

REQUEST message can be attached to an escape code. The the actual transmission of the GRANT messages. However, 

escape code informs the receiving unit that a GRANT or 40 scheduling the GRANT messages using the formula (1) may 

REQUEST message is present. The embedding of a GRANT result in a GRANTmessage scheduling conflict. The conflict 

message by the OLT 204 is illustrated in FIG. 9. An Ethernet occurs when the absolute difference between the left and 

frame 902 in transmission is shown in FIG. 9. The end of right tcrms of thc i neqU ality (2) is less than the transmission 

byte C of the Ethernet frame coincides with a transmission j^ me Q f me GRANT message 

time t G to send a GRANT message 904. The OLT then 45 ^ QLT 204 of the optical access network 202 is 

inserts an escape code 906 and the GRANT message 904 at configured to resolve me GRANT message scheduling con- 

the end of byte C of the Ethernet frame, as shown in an flict by rescheduliag the GRANT message currently being 

embedded Ethernet frame 908. In a similar manner, a scheduled for transmission. The operation of the OLT with 

REQUEST message can be embedded between Ethernet fCSpect tQ GRANT messagc scheduling conflicts is 

frames or within an Ethernet frame by an ONU. The 50 described with reference to FIG. 10. At step 1002, one of the 

receiving unit will recognize the beginning of the control 0NUs 206 2Q8 and 210 ^ selected by ^ QLT tQ sche(Jule 

sequence by reading the escape code. The receiving unit can a transmission time for a GRANT message. The ONU 

then extract the control message, e.g., three (3) bytes, that sekction may be predeflned by a fixed seance or may be 

follow the escape code before passing the rest of the dynamically adjusted in accordance with prescribed network 

received data to a standard Ethernet receiver. 5S conditions> Nexl> at step 1004j lhe transmissiorj ^ for lhe 

The GRANT messages transmitted by the OLT 204 are GRANT message to the selected ONU is tentatively sched- 

scheduled using the following formula: uled using me formuU (1) M step 1006 a determination is 

made whether the tentatively scheduled transmission time 

c I/J + rifl _ r*^ 1 ' 4- — + ^ ^ conflicts with an established transmission time period for a 

} ** 60 GRANT message to another ONU. 



g^Umax 



G l j2l ] + r t ' Vi) , If there is a conflict, the process proceeds to step 1008, 

where the tentatively scheduled transmission time is delayed 
until after the established transmission time period for the 
where conflicting GRANT message. That is, the GRANT message 

G ; (l] — time epoch when ) th Grant to i th ONU is to be 65 transmission time to the selected ONU is tentatively 
transmitted (note that G^'W 1 is a time epoch when j' h rescheduled for a time when the conflicting GRANT mes- 
Request from i th ONU is received) sage will have already been sent. After the GRANT message 
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to the selected ONU has been tentatively rescheduled, the 
process proceeds back to step 1006, where another deter- 
mination is made whether the tentatively rescheduled trans- 
mission time conflicts with an established transmission time 
period for a GRANT message to a different ONU. In this s 
fashion, the transmission time of the GRANT message to the 
selected ONU can be tentatively rescheduled until there is 
no scheduling conflict. 

However, if a determination is made at step 1006 that 
there is no scheduling conflict, the process proceeds to step 10 
1010, where the latest tentatively scheduled transmission 
time for the selected ONU is finalized as the scheduled 
transmission time for the GRANT message to the selected 
ONU. The process then proceeds back to step 1002, where 
the next ONU is selected to schedule a transmission time for 15 
a GRANT message to that ONU. 

A consequence of using such a resolution for GRANT 
message scheduling conflicts is described using an example. 
In this example, the current GRANT message Gj h ^ conflicts 
with the GRANT message G/* ] , which has already been 20 
scheduled. When the GRANT scheduling conflict is detected 
by the OUT 204, the GRANT message G/* ] will get sched- 
uled after the time when lo the end of the GRANT message 
G/* 1 is transmitted. Assuming one Gigabit per second trans- 
mission speed, as an example, the transmission time for any 25 
GRANT message is equal to 32 ns. Therefore, the GRANT 
message G^ will be delayed by at most 32 ns. The fact that 
the GRANT message G^ is being scheduled after the 
GRANT message G/^ means that the data from the ONU-h 
in a cycle j is suppose to arrive after the data from the 30 wnere 
ONU-k in a cycle i, i.e., eitherj>i or both i=i and [h]>[k]. 
Thus, the delay of the GRANT message G/ ft] will result in 
a corresponding increase of a guard band. This guard band 
increase may be further increased if the delayed GRANT 
message Gj h ^ conflicts with another GRANT message. In 35 
the extreme case, the GRANT message G ; - M may conflict 
with at most N-l GRANT messages, where N is the number 
of ONUs included in the optical access network 202. For the 
case of N-l 6 and guard band time of 5 fts } the maximum 
acquired delay is 0.48 //s, which is less than ten percent 40 
(10%) of the guard band time. An advantage of the described 
scheduling conflict resolution is that the resolution does not 
introduce any scalability issues in terms of the value of N 
because an increase in the number of ONUs can only result 
in an increase of the guard band time. 45 

Using the above-described polling scheme, the upstream 
channel of the OLT 204 is efficiently utilized to nearly one 
hundred percent (100%). However, some of the OLT 
upstream channel bandwidth is taken up by REQUEST 
messages that have to be embedded between data transmis- 50 
sions. In addition, the guard bands between the transmis- 
sions from different ONUs also take up some of the 
upstream channel bandwidth of the OLT. The guard bands 
include periods of time that are needed to readjust the 
sensitivity of the OLT receiver to receive optical signals 55 
from the ONUs that vary in distance from the OLT (burst 
mode receiving). 

During the operation of the optical access network 202, 
one or more ONUs may become disconnected due to either 
ONU failure or loss of power. Therefore, in one 60 
embodiment, the OLT 204 is designed to detect discon- 
nected ONUs, and then to reduce the frequency of GRANT 
messages that are sent to the disconnected ONUs. The 
detecting and polling procedure of the OLT with respect to 
disconnected ONUs is described with reference to FIG. 11. 65 
At step 1102, a GRANT message is transmitted from the 
OLT to a target ONU. Next, at step 1104, the OLT waits for 



a REQUEST message from the target ONU until a timeout 
interval has passed. If a REQUEST message from the target 
ONU is received within the timeout interval, the target ONU 
is not disconnected and thus, the process proceeds back to 
step 1102, where another GRANT message is transmitted to 
the target ONU during the next polling cycle. However, if a 
REQUEST message from the target ONU is not received 
within the timeout interval, the target ONU is identified as 
being disconnected, at step 1106. Next, at step 1108, a 
predefined number of polling cycles are skipped for the 
disconnected ONU. As an example, the predefined number 
of polling cycles may be designed so that the disconnected 
ONU is only polled once per minute. The process then 
proceeds back to step 1102, where another GRANT message 
is transmitted to the target ONU to determine if the target 
ONU is still disconnected. As illustrated in the process flow 
diagram of FIG. 11, if the OLT receives a REQUEST 
message from an ONU previously marked as disconnected, 
then the ONU is then identified as active and is polled in the 
next polling cycle. This procedure can also be used for a cold 
start of the optical access network. 

In this embodiment, GRANT messages are scheduled to 
be transmitted to the ONUs using the following formula: 



= MAX 



Df 



(3) 



( TIMEOUT, if ONU w is disconnected 
^ r*'', otherwise 



■■■■ j:., 

fo, 



if ONU is disconnected 
otherwise 

if ONl/W is disconnected 



otherwise. 



The above formula (3) is a modified version of the 
formula (1). For a disconnected ONU, the last known RTT 
value for that ONU cannot be used as a valid RTT value, 
since the reason for the disconnection could be, for example, 
relocation of that ONU. The formula (3) allows the OLT to 
schedule a GRANT message to a disconnected ONU with 
unknown R-TT. That is, the formula (3) allows the optical 
access network 202 to use interleaved schedule when the 
RTT values for some ONUs are unknown. 

The modified formula (3) guarantees that the OLT 204 
will not send a GRANT message to a disconnected ONU 
(with an unknown RTT) until the OLT receives the entire 
transmission from the previous ONU. Thus, data from a 
disconnected ONU with a very small RTT that suddenly 
comes alive will not collide with data from the previously 
polled ONU. In addition, the OLT will be able to schedule 
a GRANT message to the next ONU (i.e., keep the pipeline 
of the OLT full) even if the disconnected ONU remains 
disconnected. The reason is that since reply from a discon- 
nected ONU can only be received within the timeout 
interval, the data from the next ONU can safely arrive after 
the timeout period, regardless of whether the disconnected 
ONU has come alive or remains disconnected. 

An advantage of the optical access network 202 with the 
interleaved polling scheme is that there is no need to 
synchronize the ONUs. In addition, there is no need to 
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perform ranging (distance/delay equalization). Furthermore, that said data and said updated information from said remote 

since the entire scheduling and contention resolution are terminals do not overlap during transmission, said transmis- 

performed by the OLT 204, the optical access network can sion times for said grant messages substantially defining 

easily change the scheduling in real-time based on changes reception times for said request messages at said central 

in network conditions. There is no need for the ONUs to 5 terminal. 

negotiate and agree on new parameters, nor do the ONUs 4. The method of claim 3 wherein said step of scheduling 

need to switch to new settings synchronously because all the said transmission limes includes scheduling said transmis- 

ONUs are driven by GRANT messages received from the sion times such that a grant message to a particular remote 

OLT. terminal is not transmitted before a previous request mes- 

A method of transmitting optical signals in the optical sage from said particular remote terminal is received by said 

network access 202 in accordance with the present invention central terminal. 

is described with reference to FIG. 12. At step 1202, a 5. The method of claim 3 wherein said step of scheduling 

polling table is generated by the processor 222 of the OLT said transmission times includes rescheduling an original 

204 in memory 220 using the cold start procedure, as transmission time for a grant message to a rescheduled 

described above with reference to FIG. 11. The polling table transmission time when said original transmission time 

includes information about the current sizes of data waiting 15 conflicts with another transmission time for a different grant 

to be transmitted from the ONUs 206, 208 and 210 to the message. 

OLT At step 1204, transmission times for GRANT mes- 6. The method of claim 5 wherein said step of resched- 

sages to be sent are scheduled. Next, at step 1206, the uling includes rescheduling said original transmission time 

GRANT messages are selectively transmitted to the ONUs for said grant message such that said rescheduled transmis- 

in accordance with the scheduled transmission times. Each 20 sion lime is after said different grant message has been 

GRANT message indicates an authorized amount of data transmitted. 

that can be transmitted to the OLT from a receiving ONU. 7. The method of claim 1 further comprising: 
The authorized amount is dependent on the information detecting a disconnected remote terminal; and 
included in the polling table. At step 1208, the GRANT reducing the frequency of grant messages that are trans- 
messages are received by the ONUs. In response to the 25 mitted to said disconnected remote terminal 
GRANT messages, the receiving ONUs transmit REQUEST The method of claim 7 wherein said step of detecting 
messages and the authorized amounts of data that were sa jd disconnected remote terminal includes waiting a pre- 
waiting for transmission at the receiving ONUs, at step defined period for said disconnected remote terminal to 
1210. The REQUEST messages include updated informa- respond to a grant message transmitted to said disconnected 
tion about the current sizes of data waiting to be transmitted 3Q remote terminal. 

at the receiving ONUs. Next, at step 1212, the REQUEST 9. The method of claim 1 further comprising a step of 

messages and the authorized amounts of data are received by embedding said grant messages in between Ethernet frames 

the OLT. At step 1214, the polling table is updated by the or within said Ethernet frames, each grant message being 

processor of the OLT using the updated information con- embedded after a code of an Ethernet frame that is not used 

tained in the REQUEST messages. After step 1214, the 35 for Ethernet encoding, said code being utilized as an escape 

method proceeds to repeat steps 1204-1214 using the coc j e . 

updated polling table. 10. The method of claim 1 wherein said authorized 

What is claimed is: amount in said step of selectively transmitting said grant 

1. A method of transmitting data in an optical network messages is less than a predefined maximum amount, 
comprising: 40 u, The method of claim 1 wherein said optical network 

generating a table that includes information about the is a passive optical network. 

current sizes of data waiting to be transmitted from a 12. The method of claim 11 wherein said optical network 

plurality of remote terminals to a central terminal; is an Ethernet-based passive optical network. 

selectively transmitting grant messages to said remote 13. The method of claim 1 wherein each of said grant 

terminals, each grant message being indicative of a 45 messages and said request messages includes an identifica- 

permission for a targeted remote terminal to transmit an tion code field and a window size field, 

authorized amount of said data waiting at said targeted 14. The method of claim 13 wherein said Window size 

remote terminal, said authorized amount being depen- field of each of said grant messages defines said authorized 

dent on said information included in said table with amount of data permitted to be transmitted by a receiving 

regard to said targeted remote terminal; 50 remote terminal. 

receiving authorized amounts of said data from said 15. The method of claim 13 wherein said window size 

remote terminals in response to said grant messages, field of each of said request messages defines the current size 

including request messages containing updated infor- of data waiting to be transmitted to said central terminal at 

mation about the current sizes of said data waiting to be a transmitting remote terminal. 

transmitted at said remote terminals; and 55 16. The method of claim 1 wherein said table further 

updating said table using said updated information con- includes information about round trip times of data trans- 

tained in said request messages received from said mission between said central terminal and said remote 

remote terminals. terminals. 

2. The method of claim 1 wherein said step of updating I 7 - The method of claim 16 further comprising: 

said table includes subtracting a value from a new entry for 60 computing current round trip times for said remote 

said targeted remote terminal, said value corresponding to an terminals, including monitoring transmission times 

actual amount of data transmitted from said targeted remote associated with said grant messages from said central 

terminal, said new entry corresponding to said updated terminal and reception times associated with said 

information contained in a request message from said tar- authorized amounts of said data from said remote 

geted remote terminal. 65 terminals; and 

3. The method of claim 1 further comprising a step of updating said information about round trip times of data 
scheduling transmission times for said grant messages such transmission using computed current round trip times. 
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18. A method of transmitting optical signals in a point- 
to-multipoint optical network comprising: 

generating a table that contains entries of the current sizes 
of data waiting to be transmitted from a plurality of 
remote terminals to a central terminal; 

transmitting a first grant message from said central ter- 
minal to a first remote terminal, said first grant message 
being indicative of a permission for said first remote 
terminal to transmit a specific amount of data waiting 
at said first remote terminal, said specific amount being 
dependent on an entry included in said table for said 
first remote terminal; 

receiving said specific amount of said data from said first 
remote terminal at said central terminal in response to 
said first grant message, including a first request mes- 
sage containing updated information about the current 
size of said data waiting at said first remote terminal 
when said first request message was sent; and 

updating said table using said updated information con- 
tained in said first request message received from said 
first remote terminal. 

19. The method of claim 18 further comprising: 
transmitting a second grant message from said central 

terminal to a second remote terminal; 

receiving an authorized amount of said data from said 
second remote terminal at said central terminal, includ- 
ing a second request message containing updated infor- 
mation about the current size of said data waiting at 
said second remote terminal when said second request 
message was sent; 

updating said table using said updated information con- 
tained in said second request message received from 
said second remote terminal. 

20. The method of claim 19 further comprising a step of 35 
scheduling transmission times for said first and second grant 
messages such that said data and said first request message 
from said first remote terminal do not collide with said data 
and said second request message from said second remote 
terminal during transmission, said transmission times for 40 
said first and second grant messages substantially defining 
reception times for said first request message and said 
second request message at said central terminal. 

21. The method of claim 20 wherein said step of sched- 
uling said transmission times includes scheduling said trans- 45 
mission times such that said first grant message to said first 
remote terminal is not transmitted before a previous request 
message from said first remote terminal is received by said 
central terminal. 

22. The method of claim 20 wherein said step of sched- 
uling said transmission times includes rescheduling an origi- 
nal transmission time for said first grant message to a 
rescheduled transmission time when said original transmis- 
sion time conflicts with another transmission time for a 
different grant message. 

23. The method of claim 22 wherein said step of resched- 
uling includes rescheduling said original transmission time 
for said first grant message such that said rescheduled 
transmission time is after said different grant message has 
been transmitted, 

24. The method of claim 18 further comprising; 
detecting a disconnected remote terminal; and 
reducing the frequency of grant messages that are trans- 
mitted to said disconnected remote terminal. 

25. The method of claim 24 wherein said step of detecting 
said disconnected remote terminal includes waiting a pre- 
defined period for said disconnected remote terminal to 
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respond to a grant message transmitted to said disconnected 
remote terminal. 

26. The method of claim 18 wherein said step of updating 
said table includes subtracting a value from a new entry for 
said first remote terminal, said value corresponding to an 
actual amount of data transmitted from said first remote 
terminal, said new entry corresponding to said updated 
information contained in said first request message from said 
first remote terminal. 

27. The method of claim 18 further comprising a step of 
embedding said first grant message in between Ethernet 
frames or within one of said Ethernet frames, said first grant 
message being embedded after a code of an Ethernet frame 
that is not used for Ethernet encoding, said code being 
utilized as an escape code. 

28. The method of claim 18 wherein said specific amount 
in said step of transmitting said first grant message is less 
than a predefined maximum amount. 

29. The method of claim 18 wherein said point-to- 
multipoint optical network is an Ethernet-based passive 
optical network. 

30. The method of claim 18 wherein said table further 
includes information about round trip times of data trans- 
mission between said central terminal and said remote 
terminals. 

31. The method of claim 30 further comprising: 
computing a current round trip time for said first remote 

terminal, including monitoring a transmission time 
associated with said first grant message from said 
central terminal and a reception time associated with 
said specific amount of said data from said first remote 
terminal; and 

updating said information about round trip times of data 
transmission for said first remote terminal using a 
computed current round trip time. 

32. A point-to-multipoint optical network comprising: 

a plurality of remote terminals that receive and transmit 
optical data, each remote terminal configured to trans- 
mit a request message and an authorized amount of data 
waiting at said remote terminal in response to a grant 
message received by said remote terminal, said request 
message including updated information about the cur- 
rent size of data waiting at said remote terminal, said 
grant message including information that indicates said 
authorized amount; and 

a central terminal optically coupled to said remote termi- 
nals to transmit and receive said optical data, said 
central terminal comprising: 

memory that includes a table containing latest infor- 
mation about the current sizes of data waiting to be 
transmitted from said remote terminals to said cen- 
tral terminal; and 

a processor that is configured to selectively transmit 
grant messages to said remote terminals using said 
latest information contained in said table to indicate 
authorized amounts of data that can be sent by 
receiving remote terminals, said processor further 
configured to receive request messages from said 
remote terminals in response to said grant messages 
and to update said table in said memory using said 
updated information contained in said request mes- 
sages. 

33. The network of claim 32 wherein said processor of 
said central terminal is configured to update said table in said 
memory by subtracting values from new entries for selected 
remote terminals that have transmitted said request mes- 
sages to said central terminal, said values corresponding to 
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actual amounts of data transmitted from said selected remote 
terminals, said new entries corresponding to said updated 
information contained in said request messages. 

34. The network of claim 32 wherein said processor of 
said central terminal is further configured to schedule trans- 
mission times for said grant messages such that said data and 
said request messages from said remote terminals do not 
overlap during transmission, said transmission times for said 
grant messages substantially defining reception times for 
said request messages at said central terminal. 

35. The network of claim 34 wherein said processor of 
said central terminal is further configured to schedule trans- 
mission times for said grant messages such that a specific 
grant message for a particular remote terminal is not trans- 
mitted before a previous request message from said particu- 
lar remote terminal is received by said central terminal. 

36. The network of claim 34 wherein said processor of 
said central terminal is further configured to reschedule an 
original transmission time for a specific grant message to a 
rescheduled transmission time when said original transmis- 
sion time conflicts with another transmission time for a 
different grant message. 

37. The network of claim 32 wherein said processor of 
said central terminal is configured to detect disconnected 
remote terminals by identifying said remote terminals that 
have not responded to said grant messages within a timeout 
period. 

38. The network of claim 37 wherein said processor of 
said central terminal is configured to reduce the frequency of 



grant messages that are transmitted to said disconnected 
remote terminals. 

39. The network of claim 32 wherein said processor of 
said central terminal is configured to embed said grant 

5 messages in between Ethernet frames or within said Ethernet 
frames, each grant message being embedded after a code of 
an Ethernet frame that is not used for Ethernet encoding, 
said code being utilizes as an escape code. 

40. The network of claim. 32 wherein said processor of 
10 said central terminal is configured to generates said grant 

messages such that said authorized amounts of data that can 
be sent by said receiving remote terminals are less than a 
predefined maximum amount. 

41. The network of claim 32 wherein said point-to- 
15 multipoint optical network is an Ethernet-based passive 

optical network. 

42. The network of claim 32 wherein said table included 
in said memory further includes information about round 
trip times of data transmission between said central terminal 

20 and said remote terminals. 

43. The network of claim 42 wherein said processor is 
configured to compute current round trip times for said 
remote terminals by monitoring transmission times associ- 
ated with grant messages from said central terminal and 

25 reception times associated with request messages from said 
remote terminals and to update said information about round 
trip times using computed current round trip times. 
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[57] ABSTRACT 

A system, method and computer program product for pre- 
venting unnecessary retransmissions from being sent from a 
terminal such as, for example, an internet host computer, on 
a slow link. A slow link TCP optimizer receives data packets 
from a host computer and determines, based on an estimated 
round trip time, whether a data packet is a new data packet, 
a valid retransmitted data packet or an unnecessary retrans- 
mitted data packet. New data packets and valid retransmitted 
data packets are forwarded over the slow link to a remote 
terminal. Unnecessary retransmitted data packets are dis- 
carded. The estimating a round trip time is determined as the 
time it takes for a data packet to travel from the present 
invention to the remote terminal and for an acknowledgment 
of receipt to travel from the remote terminal back to the 
present invention. The estimated round trip time includes 
throughput latency that results from a slow link. The slow 
link TCP optimizer does not affect data packets that are sent 
from a host computer that properly accounts for a slow link 
when determining a round trip time. 
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SYSTEM METHOD AND COMPUTER 
PROGRAM PRODUCT FOR ELIMINATING 
UNNECESSARY RETRANSMISSIONS 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention is related to elimination of unnec- 
essary data retransmissions. More particularly, the present 
invention is related to preventing unnecessary retransmis- 
sions from being sent from a terminal, such as an internet 
host computer, on a slow link. 

2. Related Art 

Data communications systems typically employ a send 
and acknowledge scheme, whereby a first terminal sends 
data packets to a second terminal and the second terminal 
responds with acknowledge signals. Generally, if the first 
terminal does not receive an acknowledge signal within a 
prescribed period of time, the first terminal retransmits the 
data packet under the assumption that the initial transmis- 
sion was not received by the second terminal. 

The prescribed period of time is often based on an 
expected round trip time it takes for the data packet to travel 
to the second terminal and for the corresponding acknowl- 
edge signal to return to the first terminal. Round trip times 
are typically estimated by sending a sample data packet and 
measuring the time it takes to receive an acknowledge. 

Some communication links include what are referred to 
herein as "slow links." Slow links are communication links 
that add some amount of latency to the round trip time, 
wherein the latency depends upon the amount of data being 
sent. Small sample data packets are often unaffected by 
latency of slow links. Estimates of round trip times that rely 
only on small data packet round trip times thus underesti- 
mate actual round trip times. As a result, round trip times 
expire prematurely, causing unnecessary retransmissions of 
data. Unnecessary retransmissions clog communication 
links and cause other problems as well. In many situations, 
the user of the second terminal has no control over the first 
terminal and thus has no ability to require or ensure that the 
first terminal correctly estimates round trip time. 

Unnecessary data retransmissions are a problem for many 
types of data communications. In order to more fully under- 
stand the cause, effects and solution to unnecessary data 
retransmissions, data retransmissions are described below 
within the context of an internet communication system. The 
examples below are provided to illustrate the problem and 
solution of unnecessary data retransmissions. They are not 
intended to limit the scope of the present invention. 

An internet communication system includes intercon- 
nected networks that support communication among host 
computers using internet protocols. A host computer typi- 
cally executes application programs on behalf of users, 
employing network and/or internet communication services 
in support of this function. Internet host computers can span 
a wide range of sizes, speed and functions and can range in 
size from small microprocessors through workstations to 
mainframes and super computers. In function, they range 
from single -purpose hosts (such as terminal servers) to 
full-service hosts that support a variety of online network 
services, typically including remote login, file transfer and 
electronic mail. 

The internet is thus a network of networks where each 
host is directly connected to some particular network or 
networks. A connection between a host and the internet is 
only conceptual. Two hosts on the same network commu- 
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nicate with each other using the same setup protocols that 
they would use to communicate with hosts on distant 
networks. 

Individual or remote users can access the internet from 

s remote terminals (e.g., personal computers, laptop 
computers, etc.) via internet service providers (ISP). An ISP 
can also serve as an internet host computer. Remote users are 
typically connected to ISPs through a public service tele- 
communications network (PSTN). A coupling between a 

10 remote user and a PSTN is typically a slow link such as a 
PSTN cellular link or a code division multiple access 
(CDMA) cellular link, which can limit transmission to 
nominal rates such as, for example, 1200 bits per second 
(bps), 2400 bps, 4800 bps, 9600 bps, 14,400 bps, etc. These 
systems are referred to as slow links because communica- 

15 lions through these slow links tend to be slower than 
communications between hosts and between hosts and ISPs 
on the internet. 

When a host computer sends a stream of data packets 
through an ISP to a remote terminal, the slow link between 
the ISP and the remote terminal creates a bottleneck where 
data packets from the host congregate while waiting to be 
sent to the remote terminal over the slow link. As a result, 
slow links limit data throughput. 

25 A basic objective of internet design is to tolerate a wide 
range of network characteristics such as, for example, 
bandwidth, delay, packet loss, packet reordering and maxi- 
mum packet size. Accordingly, an internet engineering task 
force has generated communication specifications for inter- 

30 net host computers. Some of these specifications are avail- 
able as Request For Comments (RFCs), that are available on 
the internet at, for example, http://www.nexor.com/ public/ 
rfc/rfcs/rfc. Of particular interest here is an RFC 1122, 
available on the internet at http://www.nexor.com/pubUc/rfc/ 

35 rfcs/rfcl 122.txt, incorporated herein in its entirety by refer- 
ence. 

These RFCs provide specifications for, among other 
things, a transmission control protocol (TCP) used by inter- 
net host computers. TCP is the primary protocol for the 
40 internet. TCP provides reliable, in-sequence delivery of a 
full-duplex stream of octets (8-bit bytes). TCP is used by 
applications that require reliable, connection-oriented trans- 
port service, e.g., mail (SMTP), file transfer (FTP), and 
virtual terminal service (Telnet). 
45 Host computers typically maintain a sliding window 
within which they transmit data packets. Under RFC 1122, 
in order to prevent bottlenecks, host computers wait for an 
acknowledgment from a remote terminal when a data packet 
is sent. Host computers use the acknowledge signals to slide 
50 the window and transmit more data. 

Host computers typically set a round trip timer based on 
an estimated round trip time that it takes for a data packet to 
travel to a remote user and for an acknowledgment from the 
remote user to travel back to the host computer. When a host 
55 computer sends a data packet, the round trip timer is set. If 
an acknowledgment is not received by the expiration of the 
round trip timer, the data packet is resent on the assumption 
that the data packet was not received by the remote terminal. 
According to RFC 1122, section 4.2.2.15, titled "Retrans- 
60 mission Timeout: RFC-793 section 3.7", 

Recent Work by Jacobson [TCP:7] on Internet Congestion 
and TCP Retransmission Stability has produced a trans- 
mission algorithm combining "slow start" with "con- 
gestion avoidance". A TCP MUST implement this 
65 algorithm. 

For purposes of the present invention, it is assumed that, 
when a host computer implements a retransmission timeout 
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algorithm as required by RFC 1122, transmissions from What is needed is a system, method arid computer pro- 

internet host computers to remote users are optimized. Id gram product for optimizing data transfers from host com- 

other words, it is assumed that where a host computer puters over slow links, 
follows the requirements of RFC 1122, round trip times are 

properly estimated. s SUMMARY OF THE INVENTION 

However, it has been determined that at least some _ ... , . 

internet host computers (hereinafter "non-compliant host ^ P resent invention » a novel and improved system, 

computers" or "nonncompliant hosts") do not employ, or do method and computer program product for eliminating 

not properly employ, algorithms for optimizing data retrans- unnecessary retransmissions of data packets that are sent 

missions. More specifically, it is believed that non-compliant from, for example, an internet host computer. The present 

host computers do not take slow links into account when 1 invention receives data packets from a host computer and 

setting round trip timers. determines, based on an estimated round trip time, whether 

A host computer should calculate round trip time based on a data packet is a new data packet, a valid retransmitted data 

the sum of the actual round trip time of a small (e.g., 1 byte) packet or an unnecessary retransmitted data packet. New 

data packet and based on any slow link latency in the system. data packets and valid retransmitted data packets (i.e., 

Small data packets are typically not affected by slow links 15 out-of-order data packets), are forwarded to a remote ter- 

because their small size permits them to be sent over the minal. Unnecessary retransmitted data packets are dis- 

slow link in a single send operation and because they are carded. 

typically the first data sent to a slow link. Being the first data ^ estimate of roUQ£ , trf ^ ^ detennined as ^ time 

sent to a slow link means here is no ejasung bottle neck at for dala (favel remote and 

the slow link which might otherwise slow transmission of 20 . , , , r , - . iA t - 

the test data an ackn0W l ed S ment °f receipt to return from the remote 

e _, CS J aa * . f ♦ i* "++ a a * 1 * terminal. The estimated round trip time includes throughput 

Based on examination of actual transmitted data packets, . t . . - . y . , ° r 

«, 4 , . . , t 4 t tU • 1 latency that results from a slow hnk. 

it appears that non-compliant host computers set their round 3 . . . 

trip timers based only on the round trip time of a small (e.g., In 0DC embodiment, the present invention is implemented 

1 byte) test packet. When a non-compliant host computer 25 as a slow link TCP optimizer that includes a round trip timer, 

thereafter sends non-test data packets, which are typically data that store mformation associated with the data 

much larger than 1 byte, the data packets get delayed at the P ackels including an expected sequence number, and a 

slow link. Since the non-compliant host failed to take the discriminator that employs the round trip timer to determine 

slow link into account, the round trip timer expires before whether the data P ackets are valld data P ackets or UDneces " 

receipt of an acknowledgment signal from the remote ter- 30 sa, 7 retransmitted data packets. 

minal. The non-compliant host then retransmits the data In one embodiment, the slow link TCP optimizer treats a 

packet under the assumption that the first data packet was data packet as a valid data packet if the round trip timer has 

not received by the remote terminal. Unnecessary retrans- expired. In addition, the slow link TCP optimizer determines 

mitted data packets lead to additional latency at the slow that a data packet is a valid data packet when the round trip 

link. 35 timer has not expired and the data packet has a sequence 

In addition to increasing the delay at slow links, non- number that is not less than the expected sequence number, 

compliant hosts also mistakenly re-estimate round trip times The slow link TCP optimizer also determines that a data 

based on acknowledgment data. When a non-compliant host packet is a valid data packet when the round trip timer has 

sends a data packet, it also incorrectly sets its round trip not expired, the data packet has a sequence number that is 

timer. As a result of incorrectly setting its round trip timer, 40 less than the expected sequence number and the data packet 

the round trip timer expires before receipt of an acknowl- includes data that is not substantially similar to data in a 

edge from the remote terminal. When the round trip timer previously received data packet. The slow link TCP opti- 

expires, the non-compliant host retransmits the data packet mizer determines that a data packet is an unnecessary 

and resets the round trip timer. retransmitted data packet when the round trip timer has not 

When the first data packet is eventually received by the 45 expired, the data packet has a sequence number that is less 

remote terminal, the remote terminal sends an acknowledge than the expected sequence number and the data packet 

signal. Since the non-compliant host computer receives the includes data that is substantially similar to data in a 

acknowledge after retransmitting the data packet and after previously received data packet. 

resetting the round trip timer, the non-compliant host mis- In one embodiment, the data tables include a current 

takenly interprets the acknowledge as an acknowledgment 50 sequence number, an end of packet number, a highest 

of receipt of the retransmitted data packet rather than the sequence number and an expected sequence number. When 

initial data packet. The non-compliant host then re-estimates a data packet is a valid data packet, the slow link TCP 

the round trip time as the time when it retransmitted the data optimizer updates the data tables as follows: the end of 

packet to the time it received the acknowledge to the initial packet number is set to the sum of the TCP sequence number 

data packet. As a result, the non-compliant host expects to 55 of the data packet and the IP length field of the data packet; 

receive acknowledgment of subsequently transmitted data the expected sequence number is set to the end of packet 

packets faster than before and, thus, retransmits subsequent number when the sequence number is equal to the expected 

data packets at a higher rate than before, further adding to sequence number; the highest sequence number is set to the 

the bottleneck at the slow link. It has been observed that end of packet number when the end of packet number is 

unnecessary retransmissions from a non-compliant host 60 greater than the highest sequence number; and the expected 

computer can reduce the effective rate of data transmission sequence number is set to the highest sequence number 

from a nominal rate of 14.4 kbps to an actual data rate of 4—5 when the data packet has a sequence number that is less than 

kbps or less. the expected sequence number and the data packet includes 

One solution is to ensure that all internet host computers data that is not substantially similar to data in a previously 

implement a compliant round trip timer scheme such as, for 65 received data packet. Additionally, when a data packet is an 

example, that specified in RFC 1122. However, no such unnecessary retransmitted data packet, the slow link TCP 

mechanism or procedure currently exists. optimizer updates the data tables by setting the expected 
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sequence number to the highest sequence number. Also, 
when a timer expires, the expected sequence number is set 
to be equal to the highest sequence number. 

The present invention can be implemented in software, 
firmware, hardware or any combination thereof. The present 
invention is implemented between a slow link and a host 
computer. For example, the present invention can be imple- 
mented between a slow link and an internet service provider 
(ISP), within an ISP, between an ISP and a host, etc. The 
present invention can be employed by, for example, a 
telecommunications facility that provides communications 
between slow links (i.e., modems) and ISPs and by cellular 
telecommunications facilities that provide slow links 
between mobile telecommunication units and public service 
telephone networks (PSTNs). 

One advantage of the present invention is that it elimi- 
nates unnecessary retransmissions that are sent from a host 
computer. Another advantage of the present invention is that 
it accommodates out-of-order data packets. Another advan- 
tage of the present invention is that it does not affect data 
packets that are sent from a host computer that properly 
accounts for a slow link when determining a round trip time. 

Further features, objects, and advantages of the present 
invention will become more apparent from the detailed 
description set forth below. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The features, objects, and advantages of the present 
invention will become more apparent from the detailed 
description set forth below when taken in conjunction with 
the drawings in which like reference characters identify 
correspondingly throughout. Additionally, the left-most digit 
of a reference number identifies the drawing in which the 
reference number first appears. 

FIG. 1 is a block diagram of an interconnection between 
an internet host computer and a remote terminal through a 
slow link; 

FIG, 2 is a code division multiple access (CDMA) cellular 
telecommunications example of the slow link illustrated in 
FIG. 1; 

FIG. 3 is a block diagram of a CDPD cellular telecom- 
munications example of the slow link illustrated in FIG. 1; 

FIG, 4 is a land line modem/PSTN example of the slow 
link illustrated in FIG. 1; 

FIG. 5 is a block diagram of a slow link TCP optimizer 
that eliminates unnecessary retransmissions from a host 
computer, in accordance with the present invention; 

FIG, 6 is a block diagram of the slow link TCP optimizer 
of FIG. 5, implemented in a CDMA system; 

FIG. 7 is a block diagram of the slow link TCP optimizer 
of FIG. 5, implemented in a land line modem/PSTN system; 

FIG. 8 is a high-level process flowchart illustrating a 
method for eliminating unnecessary retransmissions from a 
host computer, in accordance with the present invention; 

FIG. 9 is a detailed process flowchart illustrating a method 
for eliminating unnecessary retransmissions from a host 
computer, in accordance with the present invention; 

FIG, 10 is a data table that can be employed by the slow 
link TCP optimizer illustrated in FIG. 5; 

FIG. 11 is a data table that can be employed by the slow 
link optimizer illustrated in FIG. 5; 

FIG. 12 is a time-line of data packets transmitted from a 
host computer; and 

FIG. 13 is a time-line of data packets transmitted from a 
non- compliant host computer. 
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DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

1. Overview of the Invention 

The present invention is a system, method and computer 
program product for preventing unnecessary retransmissions 
from being sent from a terminal such as, for example, an 
internet host computer, on a slow link. 

The present invention receives data packets from a host 
computer and determines, based on an estimated round trip 
time, whether a data packet is a new data packet, a valid 
retransmitted data packet or an unnecessary retransmitted 
data packet. New data packets and valid retransmitted data 
packets are sent to the remote terminal. Unnecessary retrans- 
mitted data packets are discarded. The present invention also 
accommodates out-of-order data packets. 

The present invention does not affect data packets that are 
sent from a compliant host computer that properly accounts 
for slow links. Thus, the present invention can be employed 
between a slow link and the internet without regard to 
whether a host computer properly accounts for a slow link. 
For example, the present invention can be employed by a 
telecommunications facility that provides communications 
between slow links (i.e., modems) and ISPs. The present 
invention can also be employed by a cellular telecommuni- 
cations facility, such as a code division multiple access 
(CDMA) system, that provides a slow link connection 
between mobile telecommunication units and the Internet. 

2. Example Environment 

The present invention can be employed in any data 
communication system that retransmits data when an 
acknowledge signal is not received within a period of time. 
In one embodiment, the present invention is employed to 
prevent sending of unnecessary retransmissions from an 
internet host computer on a slow link. A system, method and 
computer program product for preventing unnecessary 
retransmissions from being sent from an internet host com- 
puter on a slow link, are now described. The examples 
herein are provided to assist in the description of the present 
invention, not to limit it. 

To communicate using the internet system, a host com- 
puter can implement a layered set of protocols that is 
referred to in RFC 1122 as the internet protocol suite. A host 
computer typically implements at least one protocol from 
each layer. The protocol layers that are employed by the 
internet include an application layer, a transport layer, an 
internet layer and a link layer. 

The application layer is the top layer of the internet 
protocol suite. The application layer includes user protocols 
that provide service directly to users and support protocols 
that provide common system functions. Typical internet user 
protocols include Telnet for remote login, File Transfer 
Protocol (FTP) for file transfers and SMTP for electronic 
mail delivery. There can also be a number of other stan- 
dardized user protocols and private user protocols. 

The transport layer provides end-to-end communication 
services for applications. Two primary transport layer pro- 
tocols include Transmission Control Protocol (TCP) and 
User Datagram Protocol (UDP). TCP is a reliable 
connection-oriented transport service that provides end-to- 
end reliability, re-sequencing and flow control. UDP is a 
connection list ("datagram") transport service. Other trans- 
port protocols have been developed by internet research 
communities. Internet transport protocols can vary. 

In the internet layer, all internet transport protocols use an 
internet protocol (IP) to carry data from source host to 
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destination host. An IP datagram is the unit of end-to-end 
transmission in the IP protocol. An IP datagram includes an 
IP header followed by transport layer data, i.e., an IP header 
followed by a message. IP is a connection list or datagram 
internet work service, providing no end-to-end delivery 
guarantees. Thus, IP datagrams can arrive at the destination 
host damaged, duplicated, out-of-order or not at all. The 
layers above IP are responsible for reliable delivery service 
when it is required. The IP protocol includes provisions for 
addressing, type of service specification, fragmentation and 
reassembly, and security information. The internet layer can 
also employ an internet control message protocol (I CMP) 
and an IGN protocol (IGNP). 

In the link layer, in order to communicate on its directly- 
connected network, a host computer can implement the 
communication protocol that is used to interface to that 
network. The link layer can be referred to as a media access 
layer. There is a wide variety of link layer, or media access 
layer, protocols, corresponding to the many different types 
of networks. 

Referring to FIG. 1, a remote terminal 110 is connected to 
the internet 112 through a slow link 116 and an internet 
service provider (ISP) 114. Remote terminal 110 accesses an 
end of network host computer such as host computer 118 
that is coupled to internet 112. End of network host com- 
puter 118 sends data packets 120 to remote terminal 110 
through internet 112, ISP 114 and slow link 116. When 
remote terminal 110 receives a data packet 120, it sends an 
acknowledge 122 back to host computer 118. Within internet 
112, the path taken by acknowledge signals 122 can be 
different than the path taken by data packets 120. 

Referring to FIG. 2, slow link 116 is illustrated as a 
CDMA cellular telephone interconnection wherein ISP 114 
sends data packets to a standard network router 212 which 
forwards the data packets to a CDMA inner working func- 
tions (IWF) module 214. IWP 214 acts as a router between 
a CDMA network and the internet. IWP 214 sees and 
understands every TCP IP header that comes through it. 
CDMA IWF 214 sends the data packets to a base station 
controller 218 for RF transmission to a CDMA mobile unit 
216 which is coupled to remote terminal 110. 

Referring to FIG. 3, slow link 116 is illustrated as a 
cellular digital packet data (CDPD) system including a 
CDPD mobile unit 310 and a CDPD mobile data interme- 
diate system (MDIS) unit 312. 

Referring to FIG. 4, slow link 116 is illustrated as a land 
line modem/PSTN interconnection between remote terminal 
110 and a standard network router 212. The land line 
modem/PSTN interconnection includes a land line modem 
412 coupled to a PSTN 410 which is coupled to a standard 
network router 212 through a server 414. 

In order to prevent excessive queuing of data packets 120 
as shown in FIG. 1 at slow link 116, host computer 118 
typically implements an acknowledge scheme that sends up 
to a given number of data packets, or a given amount of data, 
within a sliding window. When an acknowledgment of 
receipt of a data packet is received, the window slides so that 
another data packet can be sent. 

For example, referring to the time- line of FIG. 12, using 
a sliding window 1230, host computer 118 can have, for 
example, up to three data packets outstanding at a time. 
Thus, host computer 118 can send data packet 1212 at time 
TO, followed by data packet 1214 at time Tl and data packet 
1216 at time T2. Host computer 118 then waits for acknowl- 
edges 1220 from remote terminal 110. When host computer 
receives an acknowledge for any of data packets 1212-1216, 
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window 1230 slides to permit another data packet to be sent 
by host computer 118. For example, when an acknowledge 
1220 is received at time T3 for data packet 1212, sliding 
window 1230 becomes sliding window 1232 and host com- 

s puter 118 can send a fourth data packet 1218 at time T4. 
Host computer 118 sets a round trip timer (RTT) (not 
shown) for each data packet that it sends. The RTT is an 
estimated round trip time that it takes for a data packet 120 
to be received by remote terminal 110 and for a correspond - 

10 ing acknowledge 122 to be received by host computer 118. 
If the RTT for a data packet 120 expires before receipt of 
acknowledge 122, host computer 118 presumes that the data 
packet 120 was lost prior to receipt by remote terminal 110. 
Host computer 118 then retransmits the data packet to 

15 remote terminal 110. 

Host computer 118 should calculate the RTT based on the 
sum of individual delays of the transmit chain plus any 
latency due to slow links, such as slow link 116. Host 
computer 118 can, for example, send a 1 byte packet to 

20 remote terminal 110 and measure the time between sending 
the packet and receiving an acknowledge. In FIG. 2, for 
example, there can be 80 milli-seconds (msec) of delay in 
CDMA mobile unit 216, 20 msec of delay between CDMA 
mobile 216 and base station controller 218, 40 msec delay 

25 in base station controller 218 and CDMA IWF 214 and 80 
msec delay between host 118 and CDMA IWF 214, for a 
total one way trip delay of 220 msec or a round trip delay of 
440 msec. 

30 Slow link 116 also has a latency or bottle neck throughput 
which can be, for example, 1200 bits per second (bps), 2400 
bps, 4800 bps, 9600 bps, 14,400 bps, etc. When a data 
packet is relatively small (e.g., 1 byte), the test data packet 
is affected by the slow link latency, but only by the delay 

35 described above. However, larger data packets and data 
packets that get queued in the slow link behind other data 
packets will be subjected to slow link latency that can vary 
with the slow link nominal throughput, the size of the data 
packet and size of the slow link queue. 

40 In order to properly determine RTT, host computer 118 
must estimate the slow link latency as well as the normal 
delay. Failure to do so will result in under estimating RTT. 
When RTT is under estimated, RTT will time out before a 
corresponding acknowledge 122 is received by host com- 

45 puter 118. 

For example, referring to the time-line of FIG. 13, RTT 
1310 is the actual round trip time for data packet 1212. RTT 
1312 is an incorrectly estimated round trip time that omits 
the latency due to slow link 116. RTT 1310 is not necessarily 

50 drawn to scale with RTT 1312. At the end of RTT 1312, host 
computer 118 retransmits data packet 1212 as data packet 
1314 because it did not receive an acknowledge for data 
packet 1212 before RTT 1312 expired. Unless data packet 
1212 was actually lost in transmission, retransmitted data 

55 packet 1314 is unnecessary and thus, adds to the bottleneck 
at slow link 116. 

An additional problem caused by a non-compliant host 
computer 118 is a further shortening of RTT 1312 based on 
acknowledge 1220. Host computer 118 receives acknowl- 

60 edge 1220 at time T3 as an acknowledgment of receipt of 
data packet 1212. However, since data packet 1314 is a 
retransmission of data packet 1212, acknowledge 1220 of 
data packet 1212 is substantially identical to an acknowl- 
edge that would be expected by host computer 118 for data 

65 packet 1314. Since host computer 118 reset its RTT for the 
data packet when it retransmitted it as 1314, host computer 
118 concludes that acknowledge 1220 is an acknowledge of 
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retransmitted data packet 1314. Host computer 118 then packets. Unnecessary transmissions thus do not contribute to 

re-estimates RTT based on the elapsed time 1316 between bottleneck at slow link 116. Additional details of slow link 

retransmission 1314 and acknowledge 1220. As a result, TCP optimizer 510 are provided below with reference to the 

when host computer 118 sends data packet 1218 at time T4, process flowcharts of FIGS. 8 and 9. 

RTT is set to new RTT 1318 (eg., a value equivalent to s Referring to FIG. 6, slow link TCP optimizer 510 can be 

1316), which is even shorter than the originally miscalcu- implemented in a CDMA system 610, which can be the 

laled RTT 1312. Thus, an acknowledge for data packet 1218 CDMA system illustrated inFIG. 2. In FIG. 6, slow link TCP 

will be expected within new RTT 1318. When host computer optimizer 510 is illustrated as implemented within IWF 214. 

118 fails to received an acknowledge within new RTT 1318, Alternatively, slow link TCP optimizer 510 could be imple- 

it will re-send data packet 1218 until it receives an acknowl- 10 mented between IWF 214 and base station controller 218, 

edge. between IWF 214 and ISP 114, between ISP 114 and internet 

In a slightly more complicated scenario, which has been 112 or within ISP 114. 
experienced, incorrect RTT 1312 and/or new RTT 1318 are Referring to FIG. 7, slow link TCP optimizer 510 can be 
much shorter than actual RTT 1310. As a result, host implemented in a land line modem/PSTN system 710 such 
computer 118 unnecessarily retransmits a given data packet 15 as tnat illustrated in FIG. 4. In FIG. 7, slow link TCP 
multiple times before receiving an acknowledge for the optimizer 510 is illustrated as implemented within ISP 114. 
initial sending of the data. When this scenario is repeated for Alternatively, slow link TCP optimizer 510 could be imple- 
data packets 1214 and 1216 as well, the bottleneck of slow mented as a stand-alone system between PSTN 410 and ISP 
link 116 can substantially reduce the amount of new data H4 ( between ISP 114 and internet 112 or within PSTN 410. 
sent from host computer 118 to remote terminal 110. ™ Referring to FIG. 8, a process flowchart is illustrated for 
3. Slow Link TCP Optimizer eliminating unnecessary retransmissions from a host corn- 
Referring to FIG. 5, a slow link TCP optimizer 510 puter. The process flowchart of FIG. 8 is described as 
eliminates unnecessary retransmissions from a host com- implemented by TCP optimizer 510. As will be apparent to 
puter based on a round trip timer (RTT) 512, which is one skilled in the art, the process flowchart of FIG. 8 could 
completely independent of a round trip timer in host com- 25 be implemented by a variety of systems and computer 
puter. Slow link TCP optimizer 510 can be implemented program products. The use of slow link TCP optimizer 510 
through software, firmware, hardware or any combination for the description of the process flowchart of FIG. 8 is 
thereof. Slow link TCP optimizer 510 includes a discrimi- intended as an example to illustrate the present invention, 
nator 514 that receives data packets 120 from internet host ^ not to limit it. 

computer 118 and data tables 516 that store limited infor- The steps illustrated in FIGS. 8 and 9 do not necessarily 

mation for use by discriminator 514 to determine whether a occur in the same order as illustrated in pseudo code 1410. 

packet 120 is a new packet, a valid retransmitted packet or The exact order with which the steps are performed can be 

an unnecessary retransmitted packet. rearranged, as will be recognized by one skilled in the art, so 

In one embodiment, data tables 516 store a current 35 long as a determination as to whether to forward a data 

sequence number (seq_num), an end-of-packet number packet 120 to remote terminal 110 is based on round trip 

(end__of__pkt), an expected sequence number (expected_ timer 512. 

seq_num) and a highest sequence number (highest_seq_ In FIG. 8, the process begins at step 810, where round trip 

num). These values are generated from a TCP sequence timer 512 is initialized to zero, for example. A separate RTT 

number and an IP field length that are included in each data 4Q timer 512 is initialized for every session and for each remote 

packet. terminal 110. For example, when a CDMA mobile unit 216 

Referring to FIG. 10, sample values for a current seq_ initiates a session with base station controller 218, a round 

number 1012, an end_of_pkt number 1014, an expected_ trip timer 512 is set for that session. 

seq_num 1016 and a highest_seq_mim 1018 are illustrated In step 812, discriminator 514 receives a data packet 120 

for consecutive data packets 120 that are received by slow 45 from host computer 118 and records data in data tables 516. 

link TCP optimizer 510 at times TO through T5. In this The data packet can be, for example, one of data packets 

embodiment, discriminator 514 compares the sequence 1212, 1214, 1216, 1218 or 1314. The recorded data prefer- 

number of a received packet 120 to one or more of data ably includes data packet sequence number and header 

values 1014-1018, to determine whether the received data information. This data is used in step 824, as described more 

packet is a new packet, a valid retransmitted packet or an 50 fully below. 

unnecessary retransmitted packet. i n s t ep 814, discriminator 514 determines whether RTT 
Data tables 516 typically store these values only for a 512 has expired. If RTT 512 has expired, processing pro- 
current time. The consecutive values in FIG. 10 are provided ceeds to step 815, where expected_seq_num 1016 is set to 
to illustrate the changing values over time, as described highest_seq_num. 

more fully below with reference to the process flowchart of 5S [ a s t e p 816, the data packet is sent as a valid data packet 

FIG. 9. 518 to remote terminal 110. Thus, if RTT 512 has expired, 

Slow link TCP optimizer 510 does not store a queue of the data packet is automatically treated as a valid data 

data packets 120. Instead, discriminator 514 determines packet, regardless of whether it is a first transmission of the 

whether a data packet is valid based on round trip timer 512 data packet or a retransmission of a prior data packet. More 

and data tables 516. This eliminates a need for a buffer queue go specifically, since RTT 512 has expired, it is concluded that 

which could otherwise be employed for determining all data packets that were previously sent to slow link 116 

whether a data packet 120 is a valid packet, a valid re trans- have either been received and acknowledged by remote 

mitted packet or an unnecessary retransmitted packet. terminal 110 or lost in transmission. Since compliant host 

Slow link TCP optimizer 510 passes valid packets and computers 118, by definition, do not unnecessarily re trans- 
valid retransmitted packets to slow link 116, as data packets 65 mit data packets before RTT 512 expires, the present inven- 
518, for transmission and to remote terminal 110. Slow link tion has no effect on data packets that are sent from 
TCP optimizer 510 discards unnecessary retransmitted data compliant host computers. 
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In step 818, RTT 512 is reset to an estimated round trip expected packet, data table 1010 is updated as at time Tl and 

time that it takes a data packet 518 to travel from slow link discriminator 514 passes data packets 120 to remote termi- 

TCP optimizer 510 to remote terminal 110 and for an nal 110 as data packets 518. Thus, so long as host computer 

acknowledge 122 to travel from remote terminal 110 back to 118 properly sets its internal round trip timer, it does not 

slow link TCP optimizer 510. Round trip timer 512 can be 5 send any unnecessary retransmissions and discriminator 514 

set according to RFC 1122 or any other suitable algorithm, does nothing more than update data tables 516 and pass data 

so long as it sums nominal transmission delay with any slow packets 120 to remote terminal 110 as data packets 518, 

link latency. However, if internet host 118 retransmits a data packet, 

In step 820, if another data packet is received, control discriminator 514 employs round trip timer 512 and data 

passes back to step 812 for receipt of the data packet. 10 tables 516 to determine whether the retransmission is a valid 

Otherwise, processing stops at step 822. retransmission or an unnecessary retransmission. For 

Referring back to step 814, if RTT 512 has not expired, example, referring to time T3 in FIG. 10, the next expected 

processing proceeds to step 824 where discriminator 514 data packet has a sequence number of 3. Accordingly, 

determines whether the received packet is a new packet or end_of_pkt 1014, expected_seq_num 1016 and highest 

a valid retransmitted packet. Discriminator 514 can, for 15 seq_num 1018 are updated as at time Tl. Thus, at the end 

example, compare a sequence number of the received packet of time 13, end-of-packet value 1014, expected sequence 

to data in data tables 516. number 1016 and highest sequence number 1018 are all set 

Referring to the process flowchart of FIG. 9 and data table to 4 to indicate that the next expected sequence number is 4. 

1010 (see FIG. 10), a preferred method for implementing However, at time T4, the next packet received in step 812 

step 824 is provided. Processing begins at step 910, where 20 is sequence number 2. Thus, in step 910, discriminator 514 

discriminator 514 compares the sequence number of the determines that seq_num 1012 is less than expected__seq_ 

received data packet, i.e., seq_num 1012, to expected_ num 1016 and processing proceeds to step 928 where 

seq_num 1016. Preferably, if the received data packet is the discriminator 514 declares the packet a retransmission. This 

first data packet in a sequence, slow link TCP optimizer 510 does not automatically preclude the data packet from being 

initializes end-of-packet value 1014, expected sequence 25 sent to remote terminal 110. Instead, processing proceeds to 

number value 1016 and highest sequence number 1018, as step 930 where discriminator 514 determines whether there 

illustrated at time TO. are any significant changes between the current packet and 

For example, in FIG. 10, a data packet having a sequence the prior packet. Discriminator 514 can compare, for 

number lis received and recorded at time Tl in step 812. In example, header information of the current packet and 

step 910 discriminator 514 determines whether seq_num 30 header information of the pnor data packet or prior data 

1012 is less than expected sequence number 1016. Since packets. 

seq„num 1012 for Tl is not less than expected_seq_num If there are no significant changes, processing proceeds to 

1016 for Tl, processing proceeds to step 912, where end_ step 932, where discriminator 514 declares that the packet is 

of__pkt 1014 is set to the sum of the current packet TCP an unnecessary retransmission. In step 934, expected_seq_ 

seq„num 1012 plus the current packet's IP field length. In num 1016 is set to highest_seq__num 1018. The signifi- 

other words, end-of-packet value 1014 is set to the end of the cance of step 934 is discussed below. In step 826, the data 

present sequence number which is, essentially, the beginning packet is discarded as an unnecessary retransmitted packet 

of the next logical sequence number. Thus, at time Tl, and processing proceeds to step 820 for receipt of additional 

end_of_pkt 1014 is set to 2. 4 packets. 

In step 914, discriminator 514 determines whether current The present invention is designed to accommodate, and 

seq__num 1012 is equal to expected_seq_mim 1016. recover from, unnecessary retransmissions, such as the 

Where, as at time Tl, current seq_num 1012 Tl is equal to unnecessary retransmission of data packet seq__num 2, 

expected_seq_num 1016, processing proceeds to step 916 discussed above. Referring to FIG. 10, at time T5, a data 

where expected_seq_num 1016 is set to end__of_pkt 1014. 45 packet having a sequence number of 4 is received in step 

Thus, at time Tl, expected_seq_num 1016 is shown chang- 812. 

ing from 1 to 2. In step 910, discriminator 514 determines that seq_num 

In step 918, discriminator 514 determines whether end_ 1012 is not less than expected seq_num 1016. In step 912, 

of_pkt 1014 is greater than highest_seq_num 1018. discriminator 514 sets end__of__pkt value 1014 to the sum of 

Where, as at time Tl, end_of_pkt 1014 is greater than 50 the current packet's TCP seq_num plus the current packet's 

highest_seq_num 1018, processing proceeds to step 920 IP length field, in this case 5. 

where highest_seq_num 1018 is set to end_of„pkt 1014. In step 914, discriminator 514 determines whether seq_ 

In step 922, discriminator 514 determines whether the num 1012 is equal to expected_seq_num 1016. Since 

received packet was declared a valid retransmission. Dec- seq_num 1012 is equal to expected_seq__num 1016, pro- 

laration of a packet as a valid retransmission is discussed 5S cessing proceeds to step 916 where discriminator 514 sets 

more fully below in step 936. Where, as at time Tl, the expected_seq_num 1016 to end_of„pkt 1014. 

received data packet is a new transmission, processing In step 918, discriminator 514 determines whether end_ 

proceeds to step 816 for sending of the packet. of_pkt 1014 is greater than highest_seq_num 1018. Since 

When discriminator 514 receives another packet in step end_oL_pkt 1014 is greater than highest_seq__num 1018, 

812, and if RTT 512 has not expired, processing returns to 60 processing proceeds to step 920 where discriminator 514 

step 910 where discriminator 514 determines whether the sets highesL_seq_num 1018 to end_of_pkt 1014. In step 

sequence number of the newly received packet is less than 922, discriminator 514 determines that the received data 

the expected sequence number 1016. packet is not a retransmission and processing proceeds to 

For example, referring to time T2 in FIG. 10, if the step 816 for sending of the packet, 

sequence number of the newly received data packet is 65 The present invention also accommodates out-of-order 

sequence number 2, processing proceeds just as with time receipt of data packets. Referring to FIG. 11, an example of 

Tl. As long as each subsequently received packet is the next processing of out-of-order data packets is illustrated. 
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In step 812, a data packet having a sequence number 1 is At lime T4, and in step 812, a data packet having a 

received at time Tl and recorded in seq_num 1112. sequence number of four is received and recorded in seq_ 

Accordingly, end_o£_pkt 1114, expected__seq_jium 1116 num 1112. Provided that RTT 512 has not expired, process- 

and highest_seq_num 1018 are updated in steps 910-924, mg proceeds to step 910 where discriminator 514 determines 

as at time Tl in FIG. 10. 5 that seq_num 1112 is not less than expected seq_num 1116. 

At time T2, a data packet having a sequence number of 3 i n s t C p 912, discriminator 514 sets end_of_pkt 1114 to the 

is received in step 812 and recorded in seq_num 1112. In Slim 0 f the current packet's TCP seq_num 1112 plus the 

step 910, discriminator 514 determines that the seq_num current packet's IP field length. Processing proceeds through 

1112 is not less than expected_seq_num 1116 and process- ste p gj4 an( j ^ ste p 910 

ing proceeds to step 912. In step 912, discriminator 514 sets 10 

end„of_pkt 1114 to the sum of the current data packet's In step 910, discriminator 514 determines that current 

TCP sequence number plus the current data packet's IP field seq_num 1112 is not greater than expected_seq_num 1116. 

length. In step 912, end_of_pkt is set to the sum of the current 

In step 914, discriminator 514 determines that seq_num packet's TCP seq_num 1112 plus the current packet's IP 

1112 is not equal to expected__seq_num 1116. Processing field length. 

jumps to step 918 where discriminator 514 determines that Iq m discriminator 514 deterrQ ines that seq_num 

? 7 ^Pn \ 15 8 f h }^ l - s ^- mm 1112 is not equal to expected_seq_num 1116. Processing 

n step 920, d^nminator 514 sets highes^seq.num 1118 * * discriminator 514 determines that 

to end__of_pkt 1114. In step 922, discriminator 514 deter- J , F • * ,i_ u- u * mo 

mines that the packet is not a retransmission and processing ? nd - of -?„ k \ l1 } 4 15 S reater than highest_seq_num 1118. 

proceeds to step 816 where the data packet is sent to remote ™ Jj^P 920 > highest_seq__num 1118 is set to end_of_pkt 



terminal 110. 



At time T3, a data packet having a sequence number of 2 in step 922, discriminator 514 determines that the present 

is received in step 812 and recorded in seq_num 1112. In data packet is not a retransmission. Processing proceeds to 

step 910, because current seq_num 1112 is two and slep gj^ wnere tne packet is sent to remote terminal 110. 
expected_seq_num 1116 is two, discriminator 514 deter- 25 

mines that seq_num 1112 is not less than expected_seq„ In step 812, at time T5, a data packet having a sequence 

num 1116. Processing proceeds to step 912 where end_oL_ number of five is received and recorded in seq_num 1112. 

pkt 1114 is set to the sum of the current packet's TCP Provided that RTT 512 has not expired, processing proceeds 

seq_num and the current packet's IP length field (i.e., as at time T4. 



three). 



Note that from time T3, where packet two was received 



In step 914 discriminator 514 determines that current ^ rf Qrd 6TpeeM _ fal _ jnl _ lber rema ins at three. When 

seq_mim 1112 is equal to e X pected_seq num 1116 and, in Rrr su eventual] ; as shown at time T6> for 

SteP . 916 ,'., S . elS w e ^ < ^_seq_num 1116 to end_of pk exa processing wiu reach S 16, where expected 
number 1114. In , step 918, discnrmnator 514 determines that ^ ^ ^ ^ t(j hi ^ e&l aam m8 

end_of__pkt 1114 is not greater than highest seq__jium 11a. 35 

Processing jumps to step 922, where discriminator 514 Set forth below is an example of pseudo code that 

determines that the packet is not a retransmission. Process- illustrates a method for eliminating unnecessary retransmis- 

ing then jumps to step 816 where the packet is sent to remote sions from an internet host computer in accordance with the 

terminal 110. steps described above with reference to FIGS. 8 and 9. 



pkt hdr-pkt.tcp ip__hdr; 

conncction-get_connection(pkt_hdr)//niis finds last pkt hdr for this connection 

last_pk_hdr^;o nnection.1 as t_pkt_hdr 

rtt-connection.timer 

seq_num-pkt.tcp.8eq 

old_seq_num-last_pkt__hdr.tcp.seq 

pkt_is_retx-FALSE; 

pkt_valid-TRUE; 

if(seq_num<Mpected_seo ( _num) 

{ 

pkt_is_retx«TRUE; 

if(timei_not_cxpired{rtt))&&(no_sig_ffi^ 
last_pkt_hdi)) 

pkt_valid=FALSE 

} 

if(pkt_valid==FALSE) 
{ 

expected _seq_num=highest_seq_num; 

} 

else 
{ 

set_timer(rtt ( (EST_LATENCY+THRUPUT_DELAV 
(pkt_hdr.ip.leogth))); 

end_of_pkt=seq_num»^kt_hdr.ip.length; //This is total length of the 

IP pkL 

//It is not the header- 
length of pkt. 

if(expected_s cq_num-=scq_num) 
{ 
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-continued 



expected seq_num«»end_ofL_pkt; 

} 

if(end_of_pkt>highc5t $cq_mini) 

{ 

highest scq__num=end_of_pkl; 

} 

if(pkt_is_retx) 
{ 

cxpectc d_seq_num=h ighest_js eq„num; 

} 

con nection.Las t_pkt_hdr »pki_hdr, 
transmit_Lhc_pkt_Jn_ppp__format(pkO; 

} 



Not shown in the pseudo code above is a function that is 
called when RTT timer 512 expires. The function sets 
expected_seq_num equal to highest_seq_mim and sends 
any packets that are received after RTT timer 512 expires. 
4. Conclusions 20 
Based upon the foregoing description, one skilled in the 
art will recognize that there are many suitable algorithms 
that could be employed by slow link TCP optimizer 510 for 
determining whether a data packet is a new data packet, a 
valid retransmitted data packet or an unnecessary retrans- 25 
mitted data packet without storing a queue of previously 
received data packets. One skilled in the art will also 
recognize that there are many suitable algorithms that could 
be employed by slow link TCP optimizer 510 for discrimi- 
nating between unnecessary retransmissions and valid 30 
apparent retransmissions (i.e., out-of-sequence data 
packets). 

The description of the preferred embodiments is provided 
to enable any person skilled in the art to make or use the 
present invention. While the invention has been particularly 35 
shown and described with reference to preferred embodi- 
ments thereof, it will be understood by those skilled in the 
art that various changes in form and details may be made 
therein without departing from the spirit and scope of the 
invention. c0 

What is claimed is: 

1. A method for eliminating unnecessary retransmissions 
of data packets from a first terminal, comprising the steps of: 

(1) receiving a data packet from the first terminal at a first ^ 
location; 

(2) (a) estimating at the first location a round trip time for 
a data packet to travel from the first terminal to a 
second terminal, and for an acknowledgment of receipt 

to arrive at the first terminal from the second terminal, 5Q 
wherein the round trip time is based upon a delay in 
transmission plus throughput latency resulting from a 
slow link between the first terminal the second termi- 
nal; 

(2) (b) determining whether the data packet is a valid data 55 
packet or an unnecessary retransmitted data packet 
based upon the estimated round trip time; 

(3) forwarding valid data packets to the second terminal; 
and 

(4) discarding unnecessary retransmitted data packets. 60 

2. The method according to claim 1, wherein step (2)(a) 
further comprises: 

(i) determining that the data packet is a valid data packet 
if a round trip timer has expired, wherein the round trip 
timer is set according to the estimated round trip time. 65 

3. The method according to claim 1, wherein step (2) 
further comprises: 



(a) maintaining a data table including an expected 
sequence number. 

4. The method according to claim 3, wherein step (2) 
further comprises the step of: 

(b) determining that the data packet is a valid data packet 
when the following conditions are met; 

(i) a round trip timer has not expired, and 

(ii) the data packet has a sequence number that is not 
less than the expected sequence number. 

5. The method according to claim 4, wherein step (2) 
further comprises the steps of: 

(c) maintaining a current sequence number, an end of 
packet number, a highest sequence number and the 
expected sequence number in the data table; 

(d) setting the end of packet number to a sum of a TCP 
sequence number of the data packet and an IP length 
field of the data packet; 

(e) setting the expected sequence number to the end of 
packet number if the sequence number is equal to the 
expected sequence number; and 

(f) setting the highest sequence number to the end of 
packet number if the end of packet number is greater 
than the highest sequence number. 

6. The method according to claim 3, wherein step (2) 
further comprises the step of: 

(b) determining that the data packet is a valid data packet 
when the following conditions are met; 

(i) the data packet has a sequence number that is less 
than the expected sequence number, and 

(ii) the data packet includes data that is not substan- 
tially similar to data in a previously received data 
packet. 

7. The method according to claim 6, wherein step (2) 
further comprises the steps of: 

(c) maintaining a current sequence number, an end of 
packet number, a highest sequence number, the 
expected sequence number and control flags in the data 
table; 

(d) setting the end of packet number to a sum of a TCP 
sequence number of the data packet and an IP length 
field of the data packet; 

(e) setting the expected sequence number to the end of 
packet number if the sequence number is equal to the 
expected sequence number; 

(f) setting the highest sequence number to the end of 
packet number if the end of packet number is greater 
than the highest sequence number; and 

(g) setting the expected sequence number to the highest 
sequence number. 

8. The method according to claim 3, wherein step (2) 
further comprises the step of: 
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(b) determining that the data packet is an unnecessary 
retransmitted data packet when; 

(i) the data packet has a sequence number that is less 
than the expected sequence number, 

(ii) the data packet includes data that is substantially s 
similar to data in a previously received data packet, 
and 

(iii) the timer is still running. 

9. The method according to claim 8, wherein step (2) 
further comprises the step of: 10 

(c) maintaining a current sequence number, an end of 
packet number, a highest sequence number and the 
expected sequence number in the data table; and 

(d) setting the expected sequence number to the highest 
sequence number. 15 

10. The method according to claim 1, wherein step (2) 
comprises the step of: 

(a) determining that a data packet is a valid data packet if 
the data packet is was not previously received and if the M 
data packet has a sequence number that is less than a 
sequence number of a previously received data packet. 

11. A system for eliminating unnecessary retransmissions 
of data packets from a first terminal, comprising: 

a round trip timer that estimates a round trip time that it 2 5 
takes for a data packet to travel to a second terminal and 
for an acknowledgment of receipt to return from the 
second terminal, based upon delay in transmission plus 
throughput latency resulting from a slow link; 

data tables that store information associated with the data 30 
packets including an expected sequence number; and 

a discriminator that receives the data packets from the first 
terminal, that employs said round trip timer to deter- 
mine whether the data packets are valid data packets or 
unnecessary retransmitted data packets, that forwards 35 
valid data packets to a second terminal and that dis- 
cards unnecessary retransmitted data packets. 

12. The system according to claim 11, wherein said 
discriminator comprises: 

means for determining that the data packet is a valid data 40 
packet when said round trip timer has expired. 

13. The system according to claim 12, wherein said 
discriminator comprises: 

means for determining that the data packet is a valid data 45 
packet when said round trip timer has not expired and 
the data packet has a sequence number that is not less 
than the expected sequence number. 

14. The system according to claim 13, wherein said 
discriminator comprises: 50 

means for determining that the data packet is a valid data 
packet when said round trip timer has not expired, the 
data packet has a sequence number that is less than the 
expected sequence number, and the data packet 
includes data that is not substantially similar to data in 55 
a previously received data packet. 

15. The system according to claim 14, wherein said 
discriminator further comprises: 

means for maintaining a current sequence number, an end 
of packet number, a highest sequence number and the 60 
expected sequence number in said data table; 

means for setting the end of packet number to a sum of a 
TCP sequence number of the data packet and an IP 
length field of the data packet; 
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means for setting the expected sequence number to the 
end of packet number when the sequence number is 
equal to the expected sequence number, 

means for setting the highest sequence number to the end 
of packet number when the end of packet number is 
greater than the highest sequence number; and 

means for setting the expected sequence number to the 
highest sequence number when the data packet has a 
sequence number that is less than the expected 
sequence number and the data packet includes data that 
is not substantially similar to data in a previously 
received data packet. 

16. The system according to claim 11, wherein said 
discriminator comprises: 

means for determining that the data packet is an unnec- 
essary retransmitted data packet when the data packet 
has a sequence number that is less than the expected 
sequence number and the data packet includes data that 
is substantially similar to data in a previously received 
data packet. 

17. The method according to claim 16, wherein said 
discriminator further comprises: 

means for maintaining a current sequence number, an end 
of packet number, a highest sequence number and the 
expected sequence number in said data tables; and 

means for setting the expected sequence number to the 
highest sequence number. 

18. A computer program product comprising a computer 
useable medium having computer program logic stored 
therein, said computer program logic for enabling a com- 
puter to eliminate unnecessary retransmissions from a first 
terminal, wherein said computer program logic comprises: 

means for enabling the computer to receive a data packet 
from the first terminal; 

means for enabling the computer to determine whether the 
data packet is a valid data packet or an unnecessary 
retransmitted data packet, said determination consider- 
ing a round trip time based upon delay in transmission 
plus throughput latency resulting from a slow link; 

means for enabling the computer to forward valid data 
packets to a second terminal; and 

means for enabling the computer to discard unnecessary 
retransmitted data packets. 

19. The computer program product according to claim 18, 
wherein said means for enabling the computer to determine 
whether the data packet is a valid data packet or an unnec- 
essary retransmitted data packet comprises: 

means for enabling the computer to estimate a round trip 
time that it takes for a data packet to travel to the second 
terminal and for an acknowledgment of receipt to 
return from the second terminal, based upon delay in 
transmission plus throughput latency resulting from a 
slow link; and 

means for enabling the computer to determine whether the 
data packet is a valid data packet or an unnecessary 
retransmitted data packet based upon the estimated 
round trip time. 
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